In the software industry there may be a need to review the functionality of a software application, program, module, or product. The need to review the functionality the software may be prompted by a desire to determine whether the software satisfies its design requirements and functions as expected. In some instances, there might be a need to determine what the software application, program, module or product does. For example, an existing legacy software product may be in use by a business and there might not be a complete understanding of what the software product does. In some instances, a software provider may want to or have to modify a software product (e.g., a client requests new features, a legal obligation requires a software modification, etc.). Furthermore, the changes or upgrades may be desired without having to sacrifice existing functionality. However, the exact extent of the existing functionality of the software product may not be fully understood.
An understanding of what the software product does, (i.e., the functionality of the software product), might be gained by a testing of the software product, including an examination of the data produced by an execution of the software product. Software testing may generally include four phases. The phases being (1) a setup phase to prepare the testing environment or context (i.e., the fixture), (2) an execute system under test phase wherein the software is run under prescribed test conditions, (3) a verification phase where a functionality, stability, and other aspects of the software relative to an expected result is validated, and (4) a teardown phase where the fixture is tore down and the software may be returned to normal operating configuration. Data produced by an execution of a software product may typically produce hundred or even thousands fields of data. Checking or verifying that each and every field may thus be an arduous task. In some instances, only a relatively small number of result data fields may be examined. As an example only data fields considered the most important may be verified, about 5% of the data in some instances. While a problem in the software product may manifest itself as an error in a data field resulting from the execution of the software product, such a “bug” may not be readily detected when less than all of the fields are checked.
Accordingly, a method and mechanism for efficiently verifying a software product, application, module, or program may be provided by some embodiments herein.